Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi Daniel,

I agree with you. I didn't pay attention to the fact that Squamish is 
located in a hilly area.


Greetings from Quebec's flatlands,
Tim

On 2020-03-22 14:16, Daniel @jfd553 wrote:
Hi all, sorry for this long Email.

Thanks to Tim to have comment! He wrote: “I [...] found that you can 
either align the hospital with the underlying imagery or the houses to 
the right of the task, but not both at the same time. [...]  If we 
assume that the aerial imagery data is the correctly projected [...], we 
would have to correct the position of all the buildings according to the 
underlying aerial imagery.”


Well, you are right. Actually, I did not align most of the buildings to 
the image! Why? Because unless proven otherwise, ODB data should be more 
accurate (XY) than most images available, especially in hilly areas.
Municipalities generally use aerial photos to create their maps (ODB 
data). Because these aerial photos provide multiple views of the same 
area, they can be used to compute digital elevation models (DEMs) 
showing even buildings’ height. Only once done, they can create accurate 
ortho-images (orthographic view [1]). Without an accurate DEM, objects 
location on an image is not accurate either, because we are in a 
perspective view [1].
The DEMs used to create available OSM images generally do not have a 
sufficient accuracy in mountainous areas. This is the case of the 
Squamish area where the image shows many examples of perspective views 
[1]. In flat areas, this effect is minimal, which makes it possible to 
adjust an image over a large region with a great accuracy. The only 
visible effect is then related to buildings’ height.


Regarding the hospital, it is located on a hill between two plateaus. 
The image can be adjusted with a good accuracy on the flat area near the 
river, or on the plateau on the top of the hill (potentially with 
another offset), but it is more difficult in between. I tried to adjust 
its geometry (details) from its original ODB location.


I adjust the image to surrounding buildings when I need to map a new one 
or add details to an existing one. I may also look at available GPS 
tracks to confirm general ODB data location.


Thanks again. Comments?
Daniel

[1] https://en.wikipedia.org/wiki/Orthophoto


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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi Daniel,

I had a brief look at project #173, task #20 and found that you can 
either align the hospital with the underlying imagery or the houses to 
the right of the task, but not both at the same time (Bing and ESRI bear 
the same effect). This might have to do with different 
projections/coordinate reference systems used by the data provider of 
the buildings and the one used by the aerial imagery provider.
If we assume that the aerial imagery data is the correctly projected (as 
we do as default in OSM, at least for Bing imagery), we would have to 
correct the position of all the buildings according to the underlying 
aerial imagery.


Furthermore, the buildings to be imported seem to have an odd level of 
detail. Some are pretty detailed, some are missing details at all. I did 
not only look at task #20 which you have already worked on, but also 
task #21. Not sure if they were automatically collected or if a bored 
intern had to do this - that would explain the varying quality.


Apart from the location of the buildings, you did a great job, I think.

Unfortunately, I am still working on two other projects in the tasking 
manager at the moment, so, I most probably won't be of much help on 
#173, but who knows, we are all grounded at the moment, aren't we?


Happy mapping,
Tim


On 2020-03-20 10:23, Daniel @jfd553 wrote:
Hi,

I completed more than a dozen tiles of the task #173 (Squamish). That
would be interesting if some of you could validate what I did so far, in
order to adjust the procedure if required.

Thanks.

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] Importing buildings in Canada

[Tim Elrick]

Hi John,

As stated before, I don't consider the Microsoft dataset being close to 
the minimum quality requirements I would expect from any automated 
building entry into OSM. If you just want to display buildings, you can 
download the MS dataset and use it right away - no need to import into 
OSM. I think, the MS dataset has value as proof of concept and to count 
the number of buildings in a given area (e.g. to estimate market size 
for roofers, estimate number of persons living there for desaster 
relief, etc.). I also think, when Microsoft feeds its algorithm with 
higher resolution data than they did (I don't recall, but I think they 
only used the regular Bing data) they will probably end up with building 
footprints that will meet our/my quality requirements for import into 
OSM one day.


For me, the value of OSM is having accurate information in terms of tags 
and geometry. Otherwise, we could join Wikimapia; they don't care too 
much about geometry accuracy but emphasize on content/tags of objects. 
Pretty interesting project, but different from OSM.


Cheers,
Tim

On 2020-01-17 10:40, john whelan wrote:
 >first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without
Stat Can data we are happy to import Microsoft dataset buildings as is?
Or would we wish to wait until we have some more imports done before
looking at preprocessing them in some way first.

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick, mailto:o...@elrick.de>> wrote:

I would assume in most cases the imported building footprint will be
more precise than existing data. For me, this would be a reason to
replace already existing objects. However, I think this is a case by
case decision. However, I think it is important to keep tags and
history
of buildings already existent in OSM. This is how I would
read/interpret
the import guideline stated by Nate: "If you are importing data where
there is already some data in OSM, then *you need to combine this data*
in an appropriate way or suppress the import of features with overlap
with existing data." (emphasis added by me)

However, that just means, the import, hence, is nothing easy and could
not be achieve quickly, I would assume. One way of making sure that
this
is dealt with diligently, would be setting the tasking manager to
'experienced mappers only'. We would have to ask James, who is in
charge
of the Canada Tasking Manager, how to edit/set up the 'experienced
mapper role' in the TM. It might be possible to feed in a list of
mappers manually or to set a threshold of objects/changesets that they
must have entered in OSM. However, maybe only mappers who feel
experienced enough to handle the import would contribute to the TM
project anyway and we let everyone judge on their own and don't
restrict
access.

If we were to separate the new and overlapping buildings, I am also
leaning towards Daniel's assessment. I would be afraid to cause more
issues than by doing it all at once (with a reasonable tile size, of
course).

In the end, the main point of importing this specific dataset fulfils
two purposes, in my opinion: first, to add missing buildings (if it
were
just for this purpose we could also use the much bigger Microsoft
dataset), second, to get the best geospatial representation possible in
our OSM database. That means, we defer from using the Microsoft dataset
and use the much higher quality data from the ODB. This also means that
we should replace already existing buildings (yet keeping tags and
history) wherever the ODB footprint is more precise than the
existing one.

Just my two cents here,
Tim

___
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] Importing buildings in Canada

[Tim Elrick]

I would assume in most cases the imported building footprint will be 
more precise than existing data. For me, this would be a reason to 
replace already existing objects. However, I think this is a case by 
case decision. However, I think it is important to keep tags and history 
of buildings already existent in OSM. This is how I would read/interpret 
the import guideline stated by Nate: "If you are importing data where 
there is already some data in OSM, then *you need to combine this data* 
in an appropriate way or suppress the import of features with overlap 
with existing data." (emphasis added by me)


However, that just means, the import, hence, is nothing easy and could 
not be achieve quickly, I would assume. One way of making sure that this 
is dealt with diligently, would be setting the tasking manager to 
'experienced mappers only'. We would have to ask James, who is in charge 
of the Canada Tasking Manager, how to edit/set up the 'experienced 
mapper role' in the TM. It might be possible to feed in a list of 
mappers manually or to set a threshold of objects/changesets that they 
must have entered in OSM. However, maybe only mappers who feel 
experienced enough to handle the import would contribute to the TM 
project anyway and we let everyone judge on their own and don't restrict 
access.


If we were to separate the new and overlapping buildings, I am also 
leaning towards Daniel's assessment. I would be afraid to cause more 
issues than by doing it all at once (with a reasonable tile size, of 
course).


In the end, the main point of importing this specific dataset fulfils 
two purposes, in my opinion: first, to add missing buildings (if it were 
just for this purpose we could also use the much bigger Microsoft 
dataset), second, to get the best geospatial representation possible in 
our OSM database. That means, we defer from using the Microsoft dataset 
and use the much higher quality data from the ODB. This also means that 
we should replace already existing buildings (yet keeping tags and 
history) wherever the ODB footprint is more precise than the existing one.


Just my two cents here,
Tim

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi all,

I understand your concerns, John. However, many mappers might not follow 
talk-ca. So, I guess, Daniel's suggestion to contact them, might work 
better than waiting for them to incidentally check talk-ca.


* More to finding local mappers *
By providing the overpass query I just wanted to share a different way 
of contacting active mappers in your area. The advantage of Pascal's 
Who's around me is that you can see the mappers with lots of changesets, 
ie. presumably experienced mappers. The disadvantage is that these 
changesets do not have to be from the area we are interested in 
(however, with activity center in the last 6 months we at least make 
sure they were working in our area); another disadvantage is that you 
cannot collect the names of the mappers easily (or am I missing 
something here?). The advantage of the overpass query is that you get 
that list of names easily and you can see how many objects they have 
added in your area in the past months. The disadvantage, of course, is 
that we don't know how experienced the mappers are (but maybe this 
doesn't matter).


Anyway, either approach works as Daniel already pointed out. Thanks to 
stevea, I now know that I can share Overpass queries easily:

for a geocoded area:
http://overpass-turbo.eu/s/PM9
for a bounding box:
http://overpass-turbo.eu/s/PMb

* Contacting local mappers *
I suggest we design a template letter on the wiki page that can be send 
out to local mappers that include the everything that Daniel suggested 
in his last message below.


Tim


On 2020-01-15 15:54, Daniel @jfd553 wrote:
Hi John, Tim, and the others :-)
John, I understand your concern and if it was not addressed properly, 
this could block the import again.


IMHO, we just need to make sure that we have done everything reasonable 
to inform the concerned contributors, in order to discuss the import in 
case they do not agree with it. That is why I proposed the following, in 
a previous email, concerning local mappers buy-in…


1- We contact them to explain our intentions by referring to the 
appropriate wiki pages.
2- We wait a week or two for them to respond to nothing, have concerns 
or want to help.

3- Without negative answers, we could proceed to the import.

The point 3 above make sure the project is not stalled in case there is 
no or only a few answers. The identification of local contributors using 
Neis’ tool, or the query Tim Elrick just proposed, are what I consider 
reasonable attempts for contacting the local mappers.


Daniel

-Original Message-
From: Tim Elrick via Talk-ca [mailto:talk-ca@openstreetmap.org]
Sent: Wednesday, January 15, 2020 15:12
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour tasks

*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a
list of all users in the time period specified in the area specified.

// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
// I collected users active in the last 6 months, but you can
// change that
node(newer:"{{date:6 months}}")(area.searchArea);
way(newer:"{{date:6 months}}")(area.searchArea);
relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then
'raw data directly from Overpass API'. This will generate a csv. You can
then count the number of times a name appears in your list by using
LibreOffice, R, Python or Excel. This will give you the number of
objects a user entered in the last 6 months.

If I do this for Montreal I end up with 106 names who have contributed
20 objects or more in the last half year or 46 names who have
contributed 100 objects and more.

You can then use https://www.openstreetmap.org/message/new/USERNAME by
replacing USERNAME with the names from the list to contact these users.

For areas where there is no geocodeArea in OSM you can use the
boundingbox query below. First, zoom to the area of interest (i.e. your
bounding box), then paste the following code on the left and export:

// overpass query
[out:csv(::user)];
(
node(newer:"{{date:6 months}}")({{bbox}});
way(newer:"{{date:6 months}}")({{bbox}});
relation(newer:"{{date:6 months}}")({{bbox}});
);
out meta;
// end overpass query

Tim

On 2020-01-15 12:55, Daniel @jfd553 wrote:
Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of others).

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick via Talk-ca]

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour tasks

*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a 
list of all users in the time period specified in the area specified.


// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
  // I collected users active in the last 6 months, but you can
  // change that
  node(newer:"{{date:6 months}}")(area.searchArea);
  way(newer:"{{date:6 months}}")(area.searchArea);
  relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then 
'raw data directly from Overpass API'. This will generate a csv. You can 
then count the number of times a name appears in your list by using 
LibreOffice, R, Python or Excel. This will give you the number of 
objects a user entered in the last 6 months.


If I do this for Montreal I end up with 106 names who have contributed 
20 objects or more in the last half year or 46 names who have 
contributed 100 objects and more.


You can then use https://www.openstreetmap.org/message/new/USERNAME by 
replacing USERNAME with the names from the list to contact these users.


For areas where there is no geocodeArea in OSM you can use the 
boundingbox query below. First, zoom to the area of interest (i.e. your 
bounding box), then paste the following code on the left and export:


// overpass query
[out:csv(::user)];
(
  node(newer:"{{date:6 months}}")({{bbox}});
  way(newer:"{{date:6 months}}")({{bbox}});
  relation(newer:"{{date:6 months}}")({{bbox}});
);
out meta;
// end overpass query

Tim

On 2020-01-15 12:55, Daniel @jfd553 wrote:
Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of others). So
yes, I think hosting pre-processed data in the task manager, for
approved regions, is an attractive offer. When we agree on a
municipality for pre-processing, I will contact you to make the data
available.

BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
manager. I understand that ODB data are currently converted on the fly
when requested?

*b) Task manager work units for import:*

I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
was thinking at the same importation rate, but for an hour of work. It
seems best to target 20-minute tasks.

*c) Task manager work units for checking already imported data*

According to Nate, it is definitely not faster than actively importing.
We should then keep the above setup (b).

However, what if I add a new tag to pre-processed data indicating if a
building was altered or not by the orthogonalization (and
simplification) process? For instance, /building:altered=no/, would
identify buildings that were not changed by the process and that could
be left unchanged in OSM (i.e. not imported); /building:altered=yes/ for
those who were changed by the process and that should be imported again.
The same pre-processed datasets could then be made available for all
cases. Thoughts?

*d) Finding local mappers:*

I agree with Nate’s suggestion to try contacting the top 10 mappers in
an area. Using the "main activity center" would work for most of the
contributors but selecting other overlays (.e.g. an activity center over
last 6 months) could also work great. As long as we identify who might
be interested in knowing there is an import coming.

Comments are welcome, particularly about the proposal on c)

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

[Talk-ca] TagInfo for Canada

[Tim Elrick]

After reading the weeklyOSM, I was thrilled to find TagInfo available 
for Canada as well. Thanks to Geofabrik!


You will get the tags used in Canada:
https://taginfo.geofabrik.de/north-america/canada

If you want to find the tags for your province, just add your province 
like that https://taginfo.geofabrik.de/north-america/canada/quebec



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

[Talk-ca] Importation de bâtiments de la Ville de Montréal

[Tim Elrick]

Bonjour à tous, surtout à Montréal,

Comme la discussion sur les importations de bâtiments au Canada reprend 
de plus belle, je voulais lancer la discussion au niveau local comme une 
retombée de la discussion principale sur talk-ca.


J'ai essayé de poster cela sur la liste de Montréal il y a une semaine, 
mais je n'ai pas pu joindre notre modérateur ni mes autres contacts. 
C'est pourquoi je commence maintenant la discussion ici.


*Source des données pour l'importation*
Je suggérerais de suivre plus ou moins l'importation du bâtiment comme 
décrit sur la page principale du wiki. Cependant, je suggérerais 
d'utiliser les données ouvertes de la Ville de Montréal (puisque nous 
avons le consentement de la Ville pour le faire [1]; comme Simon du LWG 
l'a déclaré ici [2], cela devrait être suffisant pour l'utiliser pour 
l'importation). Je le suggère pour deux raisons : lorsque StatCan a 
produit le jeu de données BDOI, il visait un jeu de données cohérent 
dans tout le Canada. C'est pourquoi il manque à BDOI l'information sur 
la hauteur des bâtiments (1).  De plus, il ne contient que les bâtiments 
confondus lorsqu'il y a des maisons en terrasse. Les séparateurs de 
bâtiments individuels sont fournis par la Ville de Montréal, mais dans 
un autre fichier shapefile. StatCan ne les a pas utilisés pour séparer 
les bâtiments. Par conséquent, nous obtiendrions des bâtiments de 
qualité inférieure lorsque nous utiliserions le BDOI (2). En dehors de 
cela, le BDOI est basé sur les données ouvertes de la Ville. Je suggère 
donc d'utiliser les données de la Ville de Montréal. Cela nous a permis 
aussi d'utiliser les empreintes des bâtiments pour créer des modèles 3D 
plus tard.


*Prétraitement nécessaire des données*
Les empreintes des bâtiments de la ville sont de très haute qualité car 
elles ont été dérivées d'images aériennes. Cependant, nous avons encore 
besoin de pré-traiter les données comme suggéré sur la page wiki. En 
outre, nous aurions aussi besoin d'inclure une étape supplémentaire :
la séparation des blocs de construction en bâtiments. À mon avis, les 
bâtiments devraient exister en tant que bâtiments individuels dans OSM, 
et non en tant qu'éléments des blocs. Il faut donc trouver un moyen de 
les séparer. Je sais que les cartographes d'OSM d'Ottawa n'ont pas pris 
la peine de séparer les maisons mitoyennes en bâtiments uniques et ça me 
va. Mais, je pense que cela ne suit pas le principe de la vérité de 
terrain (ground truth) et je suggère de le faire de cette façon à 
Montréal. Nous pouvons soit rechercher une automatisation de cette étape 
par FME, PostGreSQL/PostGIS, QGIS ou le faire manuellement. J'ai déjà 
regardé un peu et j'ai trouvé que c'est assez complexe car il y a 
beaucoup d'exceptions. La simplification (suppression des nœuds 
superflus) pourrait bien fonctionner avec un outil automatisé. J'ai des 
doutes sur la division des bâtiments individuels ainsi que sur 
l'orthogonalisation des maisons mitoyennes.


Qu'est-ce que vous en pensez ?

Allons-y !

Bonne journée,
Tim

+++
AGeographer sur OSM

[1] 
https://wiki.openstreetmap.org/wiki/Montr%C3%A9al/Imports/Ville_de_Montr%C3%A9al

[2] https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Thank you, Daniel, for advancing on the import! I agree with most of 
what you said below (I will reply to some details on the wiki page).


I also agree to separate the different sources as I have great 
reservations about using Microsoft's building footprints for an import 
into OSM (the outlines are simply not good enough in their topology).


Let's get this going,
Tim




On 2020-01-03 15:40, Daniel @jfd553 wrote:
Bonjour groupe, mes excuses pour ce très long courriel !-)

I have reviewed everything that has been written on the ODB import (aka
Canada Building Import) in Talk-ca and the wiki. I proposed changes to
some wiki pages (via talk tabs) to ease the discussions about this
import and the following. Now, in order to restart the import, here are
some thoughts and a proposal on how to proceed to complete the task.

*1. Issues with the ODB Data Import*

Many concerns were raised about the import. One major concern was to
obtain local communities’ buy-in in the Canadian context. Another
concern was to improve the quality of the data prior the import. The
following paragraphs intend to clear most of these concerns.

*1.1. Which data import project?*

According to the import guidelines (steps 3 & 4), a data import
explicitly refers to a single data source (ODB in our case). Discussions
about the availability and quality of Microsoft or ESRI data, while
interesting, are not relevant as they should be dealt with as other
import projects.

*1.2. What has been imported so far?*

According to what I found [1], the ODB import is completed for 21
municipalities. These imports seem to have kept OSM content’s history,
at least for the samples checked, but many problems were found. In some
case, the imports brought swimming pools in OSM because they were
included in the dataset (e.g. Moncton). In other cases, importing
buildings with accurate locations (XY) over content mapped from less
accurate imagery resulted in buildings that now overlap the street
network (e.g. Squamish). It means that all these 21 imports need to be
carefully re-examined and corrected as required.

For 12 other municipalities, the import is partial, either suspended as
requested, or because previous imports had already provided most of the
buildings (often from the same municipal provider). That said the import
will definitely improve OSM accuracy and completeness if done properly.

*2. How should ODB Data be imported?*

I will copy the following paragraphs in the “Canada Building Import”
wiki page [3] for a detailed discussion…

Since the data (ODB, OSM and imagery) differ from one municipality to
another, there can be no imports at the national or provincial level. We
have to work on a municipal basis and make sure to identify all the
problems and the corrective measures to apply when dealing with issues
like those I identified [1].

*2.1 Importing Locally*

According to the import guidelines (step 2), we must not import the data
without local buy-in. However, and contrarily to some European country,
there is usually no such thing as a local OSM community in each
municipality. However, we may find a few local mappers from time to
time. Working on a municipal basis should allow identifying these local
mappers before doing the import. I often use this tool [2] to identify
and contact local mappers. Once identified, I suggest that…

- We contact them to explain our intents by referring to appropriate
wiki pages.

- We wait a week or two to let them respond nothing, that they have
concerns, or wish to help.

- Without negative answers we could proceed to the import.

I first suggest that when a contributor wishes to import ODB for a given
municipality, he first identifies himself as responsible for the import
(we need to create an entry for each municipality somewhere in the
wiki). He can then contact local mappers, as explain above, and go ahead
with the import once everything settled. For those who already made the
import, I suggest that they review their work since many issues were
detected with some of these imports.

Since there are only a few local OSM communities in Canada, and because
Canada is large, I suggest not limiting the import of a given
municipality to the people of the concerned province or region.

*2.2 Pre-processing*

Once local mappers have agreed, some pre-processing can be done if
required.

A few months ago, I developed a tool that could be used to process the
data [4]. Concerns were raised because the application was developed
using proprietary software. So I documented the whole process and
algorithms in order to see courageous coders converting it in open
source software. In the meantime, and as long as I have access to an FME
licence, I could process the data, when necessary, prior to make it
available through the task manager.

Proposed pre-processing [4] includes:

- Reading of original ODB data,

- Removal of near collinear nodes (simplification),

- Orthogonalization of buildings (for corners having near 

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

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] NRC building footprints - from lidar

[Tim Elrick]

Hi all,

All those new sources are really exciting! Thanks for making us aware of 
the data, Keith!


I just checked the NRCan LiDAR building footprints for Montreal [1]. 
Unfortunately, they seem to have the same flaws as the Microsoft 
building footprints. The data quality for Montreal cannot keep up with 
the building footprints in the Open Building Database released by 
StatCan - it probably has to do with the altitude the LiDAR sensor was 
flown over the surface, as the OBD data for Montreal was also derived 
from LiDAR (but probably flown at a much lower altitude, hence a much 
more detailed result).


As with the Microsoft building dataset the NRCan data set is probably 
useful for emergency services and desaster relief organisations that 
only need to know the existence of buildings in an area, but not the 
exact shape. I doubt it can be used for import into OSM, however, as 
already stated in another e-mail, in remote areas it still might be good 
enough - I guess, it all depends on how you read the 'ground truth 
principle' and other 'mapping rules' in the OSM cosmos.


Like Pierre, Daniel and Nate have shown for the OBD data the NRCan data 
should at least be simplified and orthogonalized if deemed appropriate 
for importing.


Cheers,
Tim

[1] https://imgur.com/a/4eKDpcj

On 2019-04-27 09:56, keith hartley wrote:
Hi all,
Canadian Geomatics posted this data set a few months back from Natural
Resource Canada.
It's Building footprints from Lidar or high res imagery.
https://canadiangis.com/automatically-extracted-buildings-canadian-open-data.php?fbclid=IwAR22SaWwz7--LarDksVfcQuZ9RDgkVc421n9saJ_Lv8r6xq1qPSrouEF0Ww

https://open.canada.ca/data/en/dataset/7a5cda52-c7df-427f-9ced-26f19a8a64d6

 From what I can tell when placing the data over imagery it's very bang
on. Highly accurate, good shapes (unlike the bing files) and well
placed. As far as I can tell no one else has uploaded these to OSM. The
areas in manitoba are mainly where there's little to no other building
info.
I can write an upload plan on Manitoba wiki as the data is complaint
license wise. Anything else I should be looking for? The local mappers
here are pretty excited about it.

Keith




___
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

[Tim Elrick]

D'accord. Attendons que Daniel ait fini de peaufiner le pré-traitement. 
Ensuite, nous pouvons voir comment nous pouvons réaliser cela en open 
source. Je connais pas mal de R et de plus en plus de PostGIS. Bien sûr, 
tout le monde sera le bienvenu.


Tim

On 2019-03-27 16:13, Begin Daniel wrote:
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] Building Import

[Tim Elrick]

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

Re: [Talk-ca] Building Import

[Tim Elrick]

I sent Daniel a sample of Montreal (Outrement) from the Open Building 
Database and Daniel's algorithm performed really well. It could reduce 
the vertices count by 13% without loosing or even improving data quality 
(as it orthogonalized the buildings). Even difficult buildings were 
treated well [1].


As OSM is mainly built on open source tools, the OSMF tries to work with 
open source tools only and the process should be reproducible (if not 
for this import, then for the next one somewhere else in the OSM 
cosmos), I suggest, we try to resemble Daniel's pre-processing in open 
source software, e.g. PostGreSQL/PostGIS. I already found the code for 
collinearity; the orthogonalization seems to be a bit trickier, but it 
should be possible to built the process in PostGIS as well, if it was 
possible to built it in FME. What do you think?


Tim

[1] https://imgur.com/a/aCKMVb7

On 2019-03-26 13:45, Jarek Piórkowski wrote:
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

[Tim Elrick]

I think, Montreal's OSMappers would appreciate to discuss the import of 
the buildings there first on the local list. By the way, John, I have 
never said I would be taking the lead for the entirety of Québec (at 
least, at the moment). However, I feel that the import should be 
discussed on the liste OSM de Québec first.


Danny, I disagree with you on the import of building blocks. I find it 
much more tedious to discern them later, then splitting them into single 
buildings first before importing, because, I think, you need to know 
your neighbourhood very well to find unsplit buildings in the OSM 
database. Doing this for a whole town or even city (like Montreal) would 
take much longer than pre-processing.


As for the rest, I have some understanding for the impatience of 
OSMappers about the moratorium on the import - as quite some time has 
passed and the discussion hasn't really moved on nor has the development 
of the countrywide import plan [1] - last change there was beginning of 
February.


Having looked at the Microsoft data and compared quality to the Open 
Building Database in two places (Montréal, QC and Williams Lake, BC), I 
would suggest to refrain from using it as a source for importing, unless 
you verify them for small areas (but then you can almost draw them by 
hand). In dense areas like downtown Montréal the building footprints are 
in many cases plainly wrong (see my contribution to this list on 
2019-03-02, 19h57 EST), in more scattered areas and suburban landscapes 
buildings are randomly aligned and quite some buildings are missing (my 
unverified estimate is about 5-10%).


As for the Open Building database, it is important to discern the data 
by the sources as each municipality that contributed data might have 
used different methods and has different mapping standards. Now add the 
disagreement on this list about orthogonalization and building details. 
I think, this suggests breaking up the import plan in smaller batches; 
for the start it can be cloned from the original one, but the 
pre-processing and import process might differ due to how data sources 
might need to be treated as well as how local OSM communities would like 
to go forward.


What do you reckon?

Tim

[1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import


On 2019-03-15 14:01, John Whelan wrote:
Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers. How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disa gree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



___
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


___
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

[Tim Elrick]

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


__  __

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

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

[Tim Elrick]

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 clear that "if Set A doesn't have your province's or Territory's 
building data, Set B will."


Northwest Territories, Nunavut, and Yukon have populations of around 35,000 
people.  Realistically I don't think they have a group of local OSM mappers.


Please don't "write them off" so easily.  Not only does it seem "not nice," it may not be true.  A 
better approach may be to actively develop community there, difficult as that might seem.  I believe there is usually 
Internet available there in the villages (sometimes via clever and state-of-the-art methodologies) and it may be as 
simple as "shaking the trees" of the right people, then "they'll take it from there."


Essentially the problem now we no longer have a Canada wide consensus on what 
is 

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

[Tim Elrick]

Hi everyone,

Thanks John for pointing out the new dataset!

Steve, John just indicated that there is this new dataset available now. 
I am confident, that after our discussion on importing building 
footprints in Canada, the OSMappers who want to go forward with it, will 
provide the information on the import plan/wiki.


You can download the Microsoft file at the site indicated by John. The 
license information can be found there as well (as mentioned by James it 
is ODbL. It is much more extensive than the Open Building Database 
release by StatCan (> 12 million buildings vs. 4.4 million buildings).


So, I got interested and I had a look at the data for Montreal: 
https://imgur.com/a/PwuZ3Q5
I chose an area where OSM data existed. As you can see OSM hand-drawn 
buildings from Bing imagery are nicely drawn and separated.
When you compare the OSM data to the Open Building Database (OBD) data 
from StatCan (brown in my images) which draws on the données ouvertes de 
Ville de Montréal (extracted from photogrammetric imagery) you can see 
that the OBD data is somehow more precise than the OSM/Bing data, but 
the huge draw back is that the OBD data only captures the building 
outlines of attached/terraced buildings, i.e. of building blocks without 
separating single buildings (as already mentioned by me in a separated 
e-mail to the list - this is why we will have to do some pre-processing 
of the data).
When you then compare this data set to the Microsoft data set (pink in 
my images), you see that their deep neural network approach fails in 
areas with terraced houses big time. Same goes for the the city centre 
of Montreal (not shown in my images).


So, the Microsoft data set might work for areas with single homes and 
that would be helpful to fill in the blanks in remote areas, but for 
areas where we have data from the ODB, importing from the ODB might be 
better. However, caution has to be taken with ODB as well, as every 
municipality that contributed data might have contributed a different 
data source, where the quality should be check each time.


Just my two cents here.

Tim


On 2019-03-02 17:40, john whelan wrote:

Why are you planning to import it?

Cheerio John

On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea, 
mailto:stevea...@softworkers.com>> wrote:


   A responsible complement to this would be a link to license
   information, a wiki page about these data, and perhaps an Import
   Plan should those data actually be asserted to be worthy of being
   responsibly imported into OSM.

   SteveA
   California

> On Mar 2, 2019, at 2:17 PM, john whelan mailto:jwhelan0...@gmail.com>> wrote:
>
> https://github.com/Microsoft/CanadianBuildingFootprints
>
> So now there are two Open Data sources for building outlines in
   Canada.
>
> 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




On 2019-03-02 17:49, James wrote:
M$ released data as ODbL so pretty sure license is compatible

On Sat., Mar. 2, 2019, 5:27 p.m. OSM Volunteer stevea, 
mailto:stevea...@softworkers.com>> wrote:


   A responsible complement to this would be a link to license
   information, a wiki page about these data, and perhaps an Import
   Plan should those data actually be asserted to be worthy of being
   responsibly imported into OSM.

   SteveA
   California

> On Mar 2, 2019, at 2:17 PM, john whelan mailto:jwhelan0...@gmail.com>> wrote:
>
> https://github.com/Microsoft/CanadianBuildingFootprints
>
> So now there are two Open Data sources for building outlines in
   Canada.
>
> 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


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




On 2019-03-02 17:49, James wrote:
M$ released data as ODbL so pretty sure license is compatible

On Sat., Mar. 2, 2019, 5:27 p.m. OSM Volunteer stevea, 
mailto:stevea...@softworkers.com>> wrote:


   A responsible complement to this would be a link to license
   information, a wiki page about these data, and perhaps an Import
   Plan should those data actually be asserted to be worthy of being
   responsibly imported into OSM.

   SteveA
   California

> On Mar 2, 2019, at 2:17 PM, john whelan mailto:jwhelan0...@gmail.com>> 

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Thanks for the heads up. As I said, we are not in a rush here, and will 
first transfer the discussion to the Montreal list, then start a page on 
the import wiki and take it from there. On top, the pre-processing will 
be a bit of work as well.


There is lots of data for the City of Montreal that can be imported: 
fire and police stations, free wifi access, traffic lights, swimming 
pools to name but a few. For now, we are talk about including the 
address and building heights into the building import.


I know from reading the Montreal list that someone else is importing bus 
stops at the moment.


Cheers,
Tim

On 2019-02-16 13:07, John Whelan wrote:
If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus
stops you can get hold of as well.

Just be aware that we had a fairly large number of questions asked about
the license etc when we did Ottawa and one of the people questioning
referred the license to the LWG.  Even the basis of CANVEC licensing
came into question at the time.

Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as
well but that was about two years ago and I note that the LWG web site
has no mention of it so it is probably still in the queue.

Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    te

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Hi John,

Thanks for pointing me to the license website. The open data of the City 
of Montreal is licensed CC-BY 4.0 and the City has explicitly granted 
OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original open 
data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

Hi all,

After following the building import discussion for a while now, I
wanted to chime in as well.

After moving to Montréal from Germany recently, I got more engaged
with the local mappers here in MTL (beforehand, I was more analysing
OSM data scientifically).

I took part in the initial meeting of the Building Canada 2020
initiative, in which great interest in the project was expressed by
many institutions, organizations and businesses. However, apart from
Statistics Canada, municipalities and OSMappers no one seemed to be
willing to invest into the effort to support the initiative with
manpower or funding (to my knowledge). Therefore, I found it quite
impressive what StatCan has achieved with the Open Building Database
and do not share the view of some on this list that the initiative
got off on the wrong foot; but that all water under the bridge now.

So, yes, there seems to be some interest to use the data from the
Open Building Database in OSM easily. However, I am also hesitant,
that one massive import can be the answer.

I'm generally hesitant with imports as such, maybe because I was
acculturated in OSM in Germany where OSMappers value original
entries much more than secondary data. Further, I'm skeptical, that
secondary data is necessary better than original data (even from
mapathons). I initiated two mapathons with university students in
the context of Building Canada 2020. Both mapathons resulted in
mostly nice buildings, I would say - and, when there is the odd
not-so-nice building, there is still the validation step as we
always used the tasking manager [1]. By the way, both mapathons used
the ID editor; and, of course, you can square buildings in ID as
well; so, I don't really understand the ID editor bashing that
appears on this list here now and then. That said, of course, I
prefer JOSM over ID as it is the more versatile tool, but to
introduce interested persons to editing in OSM, ID is really nice.

I'm even more skeptical about imports after Yaro pointed us to the
Texas import [2]. I wonder why there was no outcry there (or maybe
there was and I did not hear about it) - the imported data is
terrible: no parallel to street buildings, no right angles,
sometimes even not the right size of building parts. Fact is that
secondary data buildings footprints can be from many different data
sources - from AutoCAD, handdrawn by a municipal GIS experts to
photogrammetric and satellite machine learning sources; all those
sources have their peculiarities, which I think, you cannot satisfy
in one import plan fits all - especially, as the Open Building
Database in Canada is stitched together from those very different
sources.

In Montreal, e.g., the source for the Open Building Database is the
données ouvertes des batiments. This is photogrammetric imagery
probably turned into AutoCAD files, which then were exported to a
shapefile and geojson. The building outlines are impressively
precise, however, the open data files contain building blocks not
single buildings [3], however, offer building dividers in a separate
shapefile (I assume due to the export from AutoCAD, see second image
in [3]). Unfortunately, the Open Building Database only included
those building blocks in their data set, making it not very easy to
import into OSM (as they do not include the building dividers).
Hence, a bit of non-trivial pre-processing of the original données
ouvert

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Hi all,

After following the building import discussion for a while now, I wanted 
to chime in as well.


After moving to Montréal from Germany recently, I got more engaged with 
the local mappers here in MTL (beforehand, I was more analysing OSM data 
scientifically).


I took part in the initial meeting of the Building Canada 2020 
initiative, in which great interest in the project was expressed by many 
institutions, organizations and businesses. However, apart from 
Statistics Canada, municipalities and OSMappers no one seemed to be 
willing to invest into the effort to support the initiative with 
manpower or funding (to my knowledge). Therefore, I found it quite 
impressive what StatCan has achieved with the Open Building Database and 
do not share the view of some on this list that the initiative got off 
on the wrong foot; but that all water under the bridge now.


So, yes, there seems to be some interest to use the data from the Open 
Building Database in OSM easily. However, I am also hesitant, that one 
massive import can be the answer.


I'm generally hesitant with imports as such, maybe because I was 
acculturated in OSM in Germany where OSMappers value original entries 
much more than secondary data. Further, I'm skeptical, that secondary 
data is necessary better than original data (even from mapathons). I 
initiated two mapathons with university students in the context of 
Building Canada 2020. Both mapathons resulted in mostly nice buildings, 
I would say - and, when there is the odd not-so-nice building, there is 
still the validation step as we always used the tasking manager [1]. By 
the way, both mapathons used the ID editor; and, of course, you can 
square buildings in ID as well; so, I don't really understand the ID 
editor bashing that appears on this list here now and then. That said, 
of course, I prefer JOSM over ID as it is the more versatile tool, but 
to introduce interested persons to editing in OSM, ID is really nice.


I'm even more skeptical about imports after Yaro pointed us to the Texas 
import [2]. I wonder why there was no outcry there (or maybe there was 
and I did not hear about it) - the imported data is terrible: no 
parallel to street buildings, no right angles, sometimes even not the 
right size of building parts. Fact is that secondary data buildings 
footprints can be from many different data sources - from AutoCAD, 
handdrawn by a municipal GIS experts to photogrammetric and satellite 
machine learning sources; all those sources have their peculiarities, 
which I think, you cannot satisfy in one import plan fits all - 
especially, as the Open Building Database in Canada is stitched together 
from those very different sources.


In Montreal, e.g., the source for the Open Building Database is the 
données ouvertes des batiments. This is photogrammetric imagery probably 
turned into AutoCAD files, which then were exported to a shapefile and 
geojson. The building outlines are impressively precise, however, the 
open data files contain building blocks not single buildings [3], 
however, offer building dividers in a separate shapefile (I assume due 
to the export from AutoCAD, see second image in [3]). Unfortunately, the 
Open Building Database only included those building blocks in their data 
set, making it not very easy to import into OSM (as they do not include 
the building dividers). Hence, a bit of non-trivial pre-processing of 
the original données ouvertes des batiments would be necessary to import 
them into OSM (as the building divider file does also include roof 
extensions and roof shapes). The local OSM group is discussing this 
pre-processing for a while now at their local meetings (we started 
discussing this even before the Building Canada 2020 initiative 
started). As the City of Montreal has granted OSM the explicit use of 
their open data file, the way forward, we think, is to pre-process the 
original files. Further, there is extensive overlap of existing 
buildings with the open data file. Therefore, the imports in Montreal 
would have to happen in very small batches to not destroy the work of 
other OSMappers.


I am also pretty skeptical about the simplification of the secondary 
data before importing that was suggested on the list here. As the data 
sources of the Open Building Database are very diverse, one 
simplification method cannot fit all data sources and can lead to 
harming the ground-truth principle. This even happened when Nate tried 
to simplify buildings by hand in Toronto [4], as pointed out by Yaro. 
There might be the odd case, where secondary data has too many nodes in 
a straight line, but, usually, I would assume, that most data sources 
stem from GIS experts or machine learning algorithms; neither would 
include more nodes than necessary for a building outline. And honestly, 
I don't buy the argument of 'too much data clutters our planet dump'. 
Storage space and processing power is no longer an issue, and I would 

Re: [Talk-ca] Multiple university departments in one building

[Tim Elrick]

Thank you, John and James.

Place d'Orleans looks nice. And, of course, we do not map for the 
renderer. However, as the departments that I want to map are on 
different floor levels and not specifically in this or that corner of 
the building, the approach I have taken is still not pleasing.


I guess, I will read into the Simple Indoor Tagging schema then and see 
how it works out.


Cheers,
Tim

On 2018-11-28 07:37, john whelan wrote:
Have a look at OSMand and see what it looks like.

Generally it is considered bad practise to map for the renderer.

As an alternative take a look at Place d'Orleans shopping center in
Orleans Ontario each unit is mapped in outline with the appropriate tags
added.

If you look at mapping a building with floors I've seen office outlines
before now.

Cheerio John

On Tue, 27 Nov 2018, 8:00 pm Tim Elrick mailto:o...@elrick.de> wrote:

Hello,

I am trying to contribute to filling the gaps on McGill campus on
OSM at
the moment and I ran into a problem which I haven't fund a satisfactory
answer for yet.

We have several buildings on campus which are home to multiple
departments, all buildings have a building name.

I looked the OSM wiki feature pages and in the OSM forum and found the
following approach as apparently standard procedure:
1) Map building outline with building = university , name= XYZ
building,
operator=McGill University
2) Add a node inside the building for each department with
office=university, description=department name
This produces irritating blue dots in the outline of the building, see
https://osm.org/go/cIrNt~j2u <https://osm.org/go/cIrNt%7Ej2u>

When I looked at other universities, I found e.g. a node with
amenity=university, name=department name. But when looking at the OSM
wiki feature page for universities[1] it says you only should use
amenity=university for the whole campus.

The office tag I found when looking for multiple businesses in one
building, but the blue dot aren't nice.

Any suggestions on how to map this elegantly?

Thank you,
Tim (aka AGeographer)

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university

___
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] Multiple university departments in one building

[Tim Elrick]

Hello,

I am trying to contribute to filling the gaps on McGill campus on OSM at 
the moment and I ran into a problem which I haven't fund a satisfactory 
answer for yet.


We have several buildings on campus which are home to multiple 
departments, all buildings have a building name.


I looked the OSM wiki feature pages and in the OSM forum and found the 
following approach as apparently standard procedure:
1) Map building outline with building = university , name= XYZ building, 
operator=McGill University
2) Add a node inside the building for each department with 
office=university, description=department name
This produces irritating blue dots in the outline of the building, see 
https://osm.org/go/cIrNt~j2u


When I looked at other universities, I found e.g. a node with 
amenity=university, name=department name. But when looking at the OSM 
wiki feature page for universities[1] it says you only should use 
amenity=university for the whole campus.


The office tag I found when looking for multiple businesses in one 
building, but the blue dot aren't nice.


Any suggestions on how to map this elegantly?

Thank you,
Tim (aka AGeographer)

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university

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

Re: [Talk-ca] Emergency Request for Tasking Manager Trainer

[Tim Elrick]

Hi Jonathan & Rob,

As John mentioned task #91, the one that we set up last, and we are
about to set up another one for our next mapathon on March 20th (on
Khairpur in Pakistan though), I am happy to help out too.

For preparing the areas of interest (aoi) the project manager needs
either a geojson or a kml or a shapefile. If you want to draw on James'
offer to set up the tasking manager and just don't have the aoi as
geojson, I am happy to convert it and send it to James.

All the best for your mapathon (if Durham wasn't so far from MTL, I
would have joined in)!,

Tim

On 2018-03-08 14:44, Jonathan Brown wrote:

Excellent. The OSM community’s support is much appreciated.

 

Jonathan

 

*From: *john whelan 
*Sent: *Thursday, March 8, 2018 2:16 PM
*To: *Jonathan Brown 
*Cc: *Matthew Darwin ; Talk-CA OpenStreetMap
; Rob Halko
; Brock Baker 
; Alasia, Alessandro (STATCAN)

*Subject: *RE: [Talk-ca] Emergency Request for Tasking Manager Trainer

 

I think Matthew or James are the people to talk to.  I suspect it might
take them an hour or so which means there is an excellent chance of it
being made available before March 29th.

 

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] Mapping buildings in Canada by 2020

[Tim Elrick]

There are in fact, quite some German based mappers, mapping in Canada.
So, you are right: let's just get more active mappers - worldwide; it
is, however, still easier to activate them locally.

I will pass on your positive experience with JOSM to my group for the
next event.

Cheers, Tim

Am 23.11.2017 um 10:32 schrieb john whelan:
>>I would have to run a query now to find out if the relative number of
active mappers is higher in one country than the other, but that's not
my point.

But how do you determine where a mapper lives and don't forget many
armchair mappers map in a different location to where they live.

JOSM and the building_tool plugin worked very well for our lot.  We did
ask them to come with JAVA installed and we only taught them enough JOSM
to map a building with the plugin.  Well we showed them a few more
things as they got more comfortable with it.

Cheerio John

On 23 November 2017 at 10:26, Tim Elrick <o...@elrick.de
<mailto:o...@elrick.de>> wrote:

Hi John,

Thanks for your feedback and background information.

I think, we are on the same page. I am concerned with quality too, while
mapping should remain enjoyable.

We shied away from JOSM for newbies because it seemed more technical to
my groups members. I personally like JOSM better, and the building
plug-in is great. Maybe I manage to convince the group to use it
next time.

I did not intend to call for experienced mappers to do all the
validation (I know it is tedious; however, correcting and esp. updating
makes OSM great and in some place much better than the official
sources). I think, that the group who initiated the mapping should
'clean up after themselves' (and I just wanted to affirm that we will do
that). I just wanted to express gratitude to mappers how do help out.

Once I am more into it, I am happy to help out validating other's work.

I did not mean to cheery pick when I quoted the validation website (I
very much appreciate the wiki page). I just wanted to make a point about
timing.

Regarding Canada, as a geographer I am fully aware of the fact Canada
having relatively less population, however, it has still almost half of
the population of Germany and the urban areas, which most of OSM mappers
are concerned with, might be relatively (to population) similar in size
(that's just a guess). I would have to run a query now to find out if
the relative number of active mappers is higher in one country than the
other, but that's not my point. The relative numbers do not matter, as
actual people do the mapping. And there, I hope we agree, the Canadian
OSM community could do with more active mappers.

Tim


Am 23.11.2017 um 07:54 schrieb john whelan:
The issue is the quality of the mapping, nothing else. I attended one of
these geoweek events and we used JOSM with the building_tool plugin. 
The mapping of buildings was accurate even though 75% of the mappers had
never used JOSM before.  There was no formal validation done but I
verified each mappers work as they did it.  I got the impression that
the mappers enjoyed the exercise and I think for me that was the most
important thing.  Mapping should be fun.

There was no mention of the work would be validated nor did we record
the mappers userids to ensure which mappers had mapped.  Other mappers
had marked tiles done on the grid.

I was under the impression that Stats Canada was involved but was later
assured by them that this was not the case.

The problem of lots of new mappers producing low quality work really
reared its head during the Nepal crisis.  I do mainly validation on HOT
projects in Africa and I ended up pulling in chunks of Africa and just
trying to clean up the map.  Currently I'm looking at one mapper who has
added more than a thousand ways with one tag I think it says
source=PGS.  Data quality is a major issue in OpenStreetMap.  Recently
someone gave up when looking for area=yes or buildings drawn in iD but
left untagged for the most part.  I think in Europe it was 100,000 or
more worldwide it was far higher and that's when the person looking at
it gave up.

There are many examples in Africa of groups of buildings being mapped as
one building and labelled building=house.  That's what we are trying to
avoid.  It is possible to correctly map a building in iD I've seen it
done but it takes time.  It is far easier to sort of roughly get it
right and roughly means not accurately.  I think the thing we need to
avoid is a feeling the mapper needs to get a tile done. That's when they
start to rush things.

Building validation?  I can think of no validator who enjoys having to
take two or three times longer to correct someones's work than it would
take them to map it in JOSM with the building_tool in the fir

Re: [Talk-ca] Mapping buildings in Canada by 2020

[Tim Elrick]

 it would be better.  Our
population density is also lower by the way if you hadn't noticed.

Cheerio John

On 22 November 2017 at 21:28, Tim Elrick <o...@elrick.de
<mailto:o...@elrick.de>> wrote:

Hello all,

As you know Open Mapping Group McGill (OMG McGill) organized one of the
mapathons last week for the town of Williams Lake, BC. For the turnout
please turn to Julia's website published earlier today on the list.

As a mentor of the group I might be the 'director' of this event
according to the proposed policy by the OSMF board. In this role, I want
to assure you that we tried to do our best to teach new mappers how to
do their job properly, as Charles stated on this list yesterday. And
judging from a preliminary analysis of the data I conducted with the
overpass api, the participants did a pretty good job.

Of course, the data needs validation, which we will conduct in the next
couple of days. However, I do not see the rush proposed on this list
earlier. Ideally, validation would happen right after the mapping event
(as set out in this manual for HOT tasks [1]). In the real world, we all
have our jobs, families and other voluntary engagements, that sometimes
do not allow to act accordingly. I further think it is not even
necessary for tasks that are not related to immediate disaster response
or include ways tagged with a highway tag (in the later case it might
confuse navigation apps if not validated right away). In many cases,
validation, or better, correction of data entered by individual mappers
(not part of group events) was (and still is) done many days or even
months after the data was entered, depending on whether an experienced
mapper has an eye on a certain region or not. With regards to buildings
in areas where there existed no respective data before, I do not see any
need for rushing.

The important thing is that the organiser of a group event makes sure
that the data entered by participants of the event *is* validated to
ensure data quality. And we will. To this end, I appreciate that
long-term members already offered to help us there (thank you,
Charles!).

I still consider mapathons a legitimate way to draw attention to OSM, to
advocate for open data, and to show the potential of OSM data and the
lack thereof in many parts of the world, including Canada. From the
experience of our first mapathon I got the impression that we instigated
a vast interest in open mapping (which, I think, is a valid goal on its
own right) and I expect quite a couple of returning participants to our
next events, in which we will train them further on the complexities to
produce good OSM data. By continuing, we might be able to motivate one
or two persons to turn into long-term mappers; this is, by the way,
totally in line with the long-tail phenomenon researchers found in all
crowd-sourcing projects.
All those reasons I mentionend, are, I think, worth it continuing doing
what we did. I would appreciate, if the attitude towards group mapping
events were less hostile on this list and on OSM as such (I am aware of
less fortunate attempts conducting group mapping events recently; but
try not blame them, but give them a hand to do it better next time - and
I know you did, but some of them apparently did not understand how
communication works in OSM). Try to give them the benefit of the doubt:
most mappers, even in group event, do this voluntarily and because they
want to enjoy extend this great geodatabase!

IMHO, OSM cannot do without those events, because we do not want to
leave the future of OSM only to businesses and their paid mappers (and
we have seen that in some countries, including Canada, there might not
be enough people who find their way to OSM without those events).

Tim


[1]

http://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager/Validating_data#When_do_we_validate.3F

<http://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager/Validating_data#When_do_we_validate.3F>


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



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

[Talk-ca] Mapping buildings in Canada by 2020

[Tim Elrick]

Hello all,

As you know Open Mapping Group McGill (OMG McGill) organized one of the
mapathons last week for the town of Williams Lake, BC. For the turnout
please turn to Julia's website published earlier today on the list.

As a mentor of the group I might be the 'director' of this event
according to the proposed policy by the OSMF board. In this role, I want
to assure you that we tried to do our best to teach new mappers how to
do their job properly, as Charles stated on this list yesterday. And
judging from a preliminary analysis of the data I conducted with the
overpass api, the participants did a pretty good job.

Of course, the data needs validation, which we will conduct in the next
couple of days. However, I do not see the rush proposed on this list
earlier. Ideally, validation would happen right after the mapping event
(as set out in this manual for HOT tasks [1]). In the real world, we all
have our jobs, families and other voluntary engagements, that sometimes
do not allow to act accordingly. I further think it is not even
necessary for tasks that are not related to immediate disaster response
or include ways tagged with a highway tag (in the later case it might
confuse navigation apps if not validated right away). In many cases,
validation, or better, correction of data entered by individual mappers
(not part of group events) was (and still is) done many days or even
months after the data was entered, depending on whether an experienced
mapper has an eye on a certain region or not. With regards to buildings
in areas where there existed no respective data before, I do not see any
need for rushing.

The important thing is that the organiser of a group event makes sure
that the data entered by participants of the event *is* validated to
ensure data quality. And we will. To this end, I appreciate that
long-term members already offered to help us there (thank you, Charles!).

I still consider mapathons a legitimate way to draw attention to OSM, to
advocate for open data, and to show the potential of OSM data and the
lack thereof in many parts of the world, including Canada. From the
experience of our first mapathon I got the impression that we instigated
a vast interest in open mapping (which, I think, is a valid goal on its
own right) and I expect quite a couple of returning participants to our
next events, in which we will train them further on the complexities to
produce good OSM data. By continuing, we might be able to motivate one
or two persons to turn into long-term mappers; this is, by the way,
totally in line with the long-tail phenomenon researchers found in all
crowd-sourcing projects.
All those reasons I mentionend, are, I think, worth it continuing doing
what we did. I would appreciate, if the attitude towards group mapping
events were less hostile on this list and on OSM as such (I am aware of
less fortunate attempts conducting group mapping events recently; but
try not blame them, but give them a hand to do it better next time - and
I know you did, but some of them apparently did not understand how
communication works in OSM). Try to give them the benefit of the doubt:
most mappers, even in group event, do this voluntarily and because they
want to enjoy extend this great geodatabase!

IMHO, OSM cannot do without those events, because we do not want to
leave the future of OSM only to businesses and their paid mappers (and
we have seen that in some countries, including Canada, there might not
be enough people who find their way to OSM without those events).

Tim


[1]
http://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager/Validating_data#When_do_we_validate.3F


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

[Talk-ca] Planning mapathon @ McGill in OSM Geo Week

[Tim Elrick, Dr.]

Hello OSMappers,

I am Tim Elrick, heading the Geographic Information Centre at McGill. I am 
involved with organizing a mapathon at McGill in Montreal in OSM Geo Week in 
November. I am reaching out to you to find local experienced mappers to support 
us in the mapathon (I followed the discussion on talk-ca in the last couple of 
weeks).

It would be great if someone could get me in touch with local OSMappers? (My 
idea was to go to the next OSM event in Montreal; however, unfortunately, it 
seems too close to OSM Geo Week, to start the contacts only then.)

Beside the mapathon, McGill students who worked as volunteers at the last HOT 
summit are currently setting up a mapping group (OMG McGill, Open Mapping Group 
McGill). They slowly want to build up OSMapping expertise to work on HOT tasks, 
Building Canada 2020 tasks as well as adding to OSM in Montreal. The group 
would appreciate to have a contact to established OSMappers here as well.

Thanks a lot!

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