<div dir="auto">My understanding is that is when we imported Ottawa we followed the normal process as detailed by Daniel and that seemed to work quite nicely.<div dir="auto"><br></div><div dir="auto">Cheerio John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2020, 2:57 PM Daniel @jfd553, <<a href="mailto:jfd553@hotmail.com">jfd553@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-CA" link="blue" vlink="purple">
<div class="m_3860365131123590172WordSection1">
<p class="MsoNormal">Hello Nate,<u></u><u></u></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...<u></u><u></u></p>
<p style="margin-right:0cm;margin-bottom:6.0pt;margin-left:35.7pt">
<u></u><span>1-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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.<u></u><u></u></p>
<p>
<u></u><span>2-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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).<u></u><u></u></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]…<u></u><u></u></p>
<p class="m_3860365131123590172MsoQuote">"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."<u></u><u></u></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...<u></u><u></u></p>
<p>
<u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Importing an ODB building when there is no corresponding one in OSM;<u></u><u></u></p>
<p>
<u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Conflating both ODB and OSM buildings when it significantly improves existing OSM content;<u></u><u></u></p>
<p>
<u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Not importing an ODB building when the corresponding one in OSM is adequate.<u></u><u></u></p>
<p class="MsoNormal">What do the others on the list think? <u></u><u></u></p>
<p class="MsoNormal">Daniel<u></u><u></u></p>
<p class="MsoNormal">[1] <a href="https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data" target="_blank" rel="noreferrer">
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data</a><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></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 lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Nate Wessel [mailto:<a href="mailto:bike756@gmail.com" target="_blank" rel="noreferrer">bike756@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, January 16, 2020 10:38<br>
<b>To:</b> Daniel @jfd553; <a href="mailto:talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">talk-ca@openstreetmap.org</a><br>
<b>Subject:</b> Re: [Talk-ca] FW: Re: Importing buildings in Canada<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></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.
<u></u><u></u></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.
<u></u><u></u></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.<u></u><u></u></p>
<p>Best,<u></u><u></u></p>
<div>
<p>Nate Wessel<span style="font-size:10.0pt">, PhD<br>
Planner, Cartographer, Transport Nerd<br>
<a href="https://www.natewessel.com" target="_blank" rel="noreferrer"><span style="text-decoration:none">NateWessel.com</span></a></span>
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Thanks for the quick replies!<u></u><u></u></p>
<p class="MsoNormal">Now, about...<u></u><u></u></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><u></u><u></u></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.<u></u><u></u></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?<u></u><u></u></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><u></u><u></u></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.<u></u><u></u></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><u></u><u></u></p>
<p class="MsoNormal">According to Nate, it is definitely not faster than actively importing. We should then keep the above setup (b).<u></u><u></u></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?<u></u><u></u></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><u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal">Comments are welcome, particularly about the proposal on c)<u></u><u></u></p>
<p class="MsoNormal">Daniel<u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
</blockquote>
</div>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote></div>