<div dir="auto">I could set the task up to be seen only by validators+ which I then can sst individual users as validators</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu., Jan. 16, 2020, 10:10 p.m. Tim Elrick, <<a href="mailto:osm@elrick.de">osm@elrick.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would assume in most cases the imported building footprint will be <br>
more precise than existing data. For me, this would be a reason to <br>
replace already existing objects. However, I think this is a case by <br>
case decision. However, I think it is important to keep tags and history <br>
of buildings already existent in OSM. This is how I would read/interpret <br>
the import guideline stated by Nate: "If you are importing data where <br>
there is already some data in OSM, then *you need to combine this data* <br>
in an appropriate way or suppress the import of features with overlap <br>
with existing data." (emphasis added by me)<br>
<br>
However, that just means, the import, hence, is nothing easy and could <br>
not be achieve quickly, I would assume. One way of making sure that this <br>
is dealt with diligently, would be setting the tasking manager to <br>
'experienced mappers only'. We would have to ask James, who is in charge <br>
of the Canada Tasking Manager, how to edit/set up the 'experienced <br>
mapper role' in the TM. It might be possible to feed in a list of <br>
mappers manually or to set a threshold of objects/changesets that they <br>
must have entered in OSM. However, maybe only mappers who feel <br>
experienced enough to handle the import would contribute to the TM <br>
project anyway and we let everyone judge on their own and don't restrict <br>
access.<br>
<br>
If we were to separate the new and overlapping buildings, I am also <br>
leaning towards Daniel's assessment. I would be afraid to cause more <br>
issues than by doing it all at once (with a reasonable tile size, of <br>
course).<br>
<br>
In the end, the main point of importing this specific dataset fulfils <br>
two purposes, in my opinion: first, to add missing buildings (if it were <br>
just for this purpose we could also use the much bigger Microsoft <br>
dataset), second, to get the best geospatial representation possible in <br>
our OSM database. That means, we defer from using the Microsoft dataset <br>
and use the much higher quality data from the ODB. This also means that <br>
we should replace already existing buildings (yet keeping tags and <br>
history) wherever the ODB footprint is more precise than the existing one.<br>
<br>
Just my two cents here,<br>
Tim<br>
</blockquote></div>