<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Daniel, <br>
</p>
<p>The section you cite from the import guidelines seems to support
my position. Perhaps that means I haven't explained my thoughts
well? It says:<br>
</p>
<p>"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.
Only where you have explicit support, which is highly unusual,
should you replace current data with your imported data."<br>
</p>
<p> OSM is not all that dynamic - if it was, we wouldn't be talking
about an import. We should do our best to align the data we're
thinking of bringing in with gaps in the existing data. That's
what conflation is all about. We should not systematically change
existing data. That's called an automated edit and is governed by
different policies than an import. <br>
</p>
<p>I'm not saying any plan is perfect - there will be gaps and
overlaps, of course. But that doesn't mean we don't try at all. <br>
</p>
<p>Toronto has hundreds of thousands of buildings in OSM. They are
not going to be compared manually, one by one if there is an
import. <br>
</p>
<p>--</p>
<p>And again, I'm not saying not to do explicit building conflation
and check for updated geometries - I'm just saying that it needs
to be a separate process if it happens. <br>
</p>
<p>Best,<br>
</p>
<div class="moz-signature">
<p> Nate Wessel<small>, PhD<br>
Planner, Cartographer, Transport Nerd<br>
<a href="https://www.natewessel.com"
style="text-decoration:none;">NateWessel.com</a></small>
</p>
</div>
<div class="moz-cite-prefix">On 2020-01-16 2:56 p.m., Daniel @jfd553
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:YQXPR01MB24541E2746EE8EE58BB32F0694360@YQXPR01MB2454.CANPRD01.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0cm;
margin-right:0cm;
margin-bottom:10.0pt;
margin-left:0cm;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:10.0pt;
margin-left:36.0pt;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
p.MsoQuote, li.MsoQuote, div.MsoQuote
{mso-style-priority:29;
mso-style-link:"Quote Char";
margin-top:0cm;
margin-right:0cm;
margin-bottom:10.0pt;
margin-left:0cm;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;
mso-fareast-language:EN-US;
font-style:italic;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:EN-US;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.QuoteChar
{mso-style-name:"Quote Char";
mso-style-priority:29;
mso-style-link:Quote;
font-family:"Calibri","sans-serif";
color:black;
mso-fareast-language:EN-US;
font-style:italic;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1346008966;
mso-list-type:hybrid;
mso-list-template-ids:1178004198 -169703656 269025283 269025285 269025281 269025283 269025285 269025281 269025283 269025285;}
@list l0:level1
{mso-level-start-at:2;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1393698313;
mso-list-type:hybrid;
mso-list-template-ids:796801530 1522293942 269025305 269025307 269025295 269025305 269025307 269025295 269025305 269025307;}
@list l1:level1
{mso-level-text:%1-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello Nate,<o:p></o:p></p>
<p class="MsoNormal">I understand that you don’t like to see an
import process that both bring in new objects and overwrite
existing ones. You also suggest removing "overlapped" building
from ODB prior to import it. Such pre-processing, that would
ensure there will be no buildings "overwrite" during the
import, is not realistic (i.e. you will need to overwrite some
buildings anyway). Here are two reasons why it would be
difficult...<o:p></o:p></p>
<p class="MsoListParagraphCxSpFirst"
style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:6.0pt;margin-left:35.7pt;mso-add-space:auto;text-indent:-17.85pt;mso-list:l1
level1 lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">1-<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->OSM is a dynamic project and,
unless you can "clean" the data on the fly, you will end up
with overlaps since some contributors will have added
buildings in the meantime.<o:p></o:p></p>
<p class="MsoListParagraphCxSpLast"
style="text-indent:-18.0pt;mso-list:l1 level1 lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">2-<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->One cannot assume that an OSM
building, and its ODB counterpart, will be found at the same
location (look at DX and DY columns in ODB inventory tables).
These are averages, which means there are larger offsets
between both datasets (i.e. you won’t get a match between
buildings, or get a match with the wrong ones).<o:p></o:p></p>
<p class="MsoNormal">The only realistic option is then to
manually delete the ODB buildings if they overlap OSM ones.
Here is what the import guideline suggests [1]…<o:p></o:p></p>
<p class="MsoQuote">"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."<o:p></o:p></p>
<p class="MsoNormal">Therefore, importing data and using a
conflation process is not unusual. Again, I understand that in
case of an overlap, you go for the last option (suppress the
import building). I am rather inclined toward using conflation
when necessary, which means...<o:p></o:p></p>
<p class="MsoListParagraphCxSpFirst"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Importing an ODB building when
there is no corresponding one in OSM;<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Conflating both ODB and OSM
buildings when it significantly improves existing OSM content;<o:p></o:p></p>
<p class="MsoListParagraphCxSpLast"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Not importing an ODB building
when the corresponding one in OSM is adequate.<o:p></o:p></p>
<p class="MsoNormal">What do the others on the list think? <o:p></o:p></p>
<p class="MsoNormal">Daniel<o:p></o:p></p>
<p class="MsoNormal">[1] <a
href="https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data"
moz-do-not-send="true">
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data</a><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"
style="margin-bottom:0cm;margin-bottom:.0001pt;line-height:normal">
<b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:EN-CA"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:EN-CA"
lang="EN-US"> Nate Wessel [<a class="moz-txt-link-freetext" href="mailto:bike756@gmail.com">mailto:bike756@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, January 16, 2020 10:38<br>
<b>To:</b> Daniel @jfd553; <a class="moz-txt-link-abbreviated" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>
<b>Subject:</b> Re: [Talk-ca] FW: Re: Importing
buildings in Canada<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Responding to point C below,<br>
I would strongly suggest that we not confuse the process of
importing new data with that of updating/modifying existing
data in the OSM database. One of the things I really disliked
about the initial building import was that it overwrote
existing data at the same time that new data was brought in.
These are really two separate import processes and require
very different considerations.
<o:p></o:p></p>
<p>We can certainly consider using this dataset to
improve/update existing building geometries, but I think that
is a separate process from the import we are discussing here.
To keep things simple for this import, I would suggest
removing any building from the import dataset that intersects
with an existing building in the OSM database. That is, let's
not worry about conflation for now, and come back and do that
work later if we still feel there is a strong need for it.
<o:p></o:p></p>
<p>I see the main point of this effort as getting more complete
coverage - it we want to use the dataset to do quality
assurance on existing data, that is a whole other discussion.<o:p></o:p></p>
<p>Best,<o:p></o:p></p>
<div>
<p>Nate Wessel<span style="font-size:10.0pt">, PhD<br>
Planner, Cartographer, Transport Nerd<br>
<a href="https://www.natewessel.com"
moz-do-not-send="true"><span
style="text-decoration:none">NateWessel.com</span></a></span>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">On 2020-01-15 12:55 p.m., Daniel @jfd553
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Thanks for the quick replies!<o:p></o:p></p>
<p class="MsoNormal">Now, about...<o:p></o:p></p>
<p class="MsoNormal"
style="margin-bottom:0cm;margin-bottom:.0001pt"><b><span
style="font-size:12.0pt;line-height:115%">a) Data
hosting:</span></b><o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"
style="margin-bottom:0cm;margin-bottom:.0001pt"><b><span
style="font-size:12.0pt;line-height:115%">b) Task
manager work units for import:</span></b><o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"
style="margin-bottom:0cm;margin-bottom:.0001pt"><b><span
style="font-size:12.0pt;line-height:115%">c) Task
manager work units for checking already imported data</span></b><o:p></o:p></p>
<p class="MsoNormal">According to Nate, it is definitely not
faster than actively importing. We should then keep the
above setup (b).<o:p></o:p></p>
<p class="MsoNormal">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,
<i>building:altered=no</i>, would identify buildings that
were not changed by the process and that could be left
unchanged in OSM (i.e. not imported);
<i>building:altered=yes</i> 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?<o:p></o:p></p>
<p class="MsoNormal"
style="margin-bottom:0cm;margin-bottom:.0001pt"><b><span
style="font-size:12.0pt;line-height:115%">d) Finding
local mappers:</span></b><o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal">Comments are welcome, particularly about
the proposal on c)<o:p></o:p></p>
<p class="MsoNormal">Daniel<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</body>
</html>