<div dir="ltr">Hi all-<div><br></div><div>Have there been any ideas about how we want to handle the import process? </div><div><br></div><div>My thoughts are that this could be treated as a unified project for "simple" imports that will not be conflating the footprints with other data (e.g. address points). My thought is we could adopt a streamlined process like this to avoid filling up the imports lists when the experience of the mapper needs to be reviewed rather than the actual import process itself:</div><div><ol><li>Write a project-level wiki page with standard instructions and tips with community feedback</li><li>Have a table on the page (and maybe the Import Catalog) for local groups or users that would like to "claim" the import in a certain area and track import/validation progress.<br></li><li>Get a few volunteers from the community who can serve as "project managers" to offer guidance and validation</li><li>When a new user starts the import process, they complete a small test area and then message a project manager to get thumbs up and feedback before continuing on with the import</li><li>We all use a special #bingbuildings changeset hashtag so that we can monitor and track progress</li><li>Optionally, set up a project in the OSM-US tasking manager when the import is complete for validation purposes by the community at-large.</li></ol><div>If someone is running an import that conflates the footprints with other datasets (e.g. address points), that would go through the normal community review process since we'll have a separate license and process to review. </div></div><div><br></div><div>Thanks,</div><div><br></div><div>Andrew</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018 at 12:32 PM Greg Morgan <<a href="mailto:dr.kludge.gm@gmail.com" target="_blank">dr.kludge.gm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 4, 2018 at 1:34 AM, Christoph Hormann <span dir="ltr"><<a href="mailto:osm@imagico.de" target="_blank">osm@imagico.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Greg,<br>
<br>I will comment on a few of the new things you have written but like to <br>
emphasize this is still not an import review because a lot of <br>
information required for that is missing. You could however read up <br>
old discussions on previous building imports here to get an idea on the </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">requirements and suggestions made for those.<br></blockquote><div> </div><div>Got it. It is not a review but a helpful number of ideas. Thank you for your time. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> [...] In my early opinion, the foot prints are no<br>
<span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-">> better nor no worse than a craft mapper,s drawing<br></span></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-">
</span>This is always a pretty meaningless comparison because it is apples and <br>
peaches. When i talk about "quality aspects" i mean quantifiable <br>
measures of quality.<br>
<br>
> [...] As your<br>
<span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-">> other post provided an idea of starting with Montana, that will not<br>
> be useful in my case. <br>
<br>
</span>I suggested rural Montana might be a good place to start if you <br>
intend "to poke the data for quality issues". Since that is not what <br>
you want to do my suggestion is pretty useless for you obviously.<br>
<span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-"><br>
> > Microsoft's process documentation contains a number of hints that<br>
> > indicate things can go wrong in the process in ways that are likely<br>
> > to produce significant errors of kinds that are very unlikely to<br>
> > happen in manual mapping. Without having reliable data on how<br>
> > often these things do happen (and how this varies between different<br>
> > geographic settings) you would essentially be doing a blind import.<br>
><br></span></blockquote><div> </div><div>Christoph, as an analogy you have read that you can get sun burnt if you go outside. Now you are afraid to go outside because you read about the resulting skin cancer. Microsoft is just saying that the data us good but use at your own risk. They also point out that we should go through the import process. Keeping up with the analogy, I have been sun burnt in Montana, Wyoming, Utah, Colorado, California, and Arizona for sure. There are other states where I have been sun burnt but they are too numerous to list. My point is that I understand what is rural America in all the states listed. The sample I have provided so far is in rural Arizona. It is not in metro Phoenix. I can parse Montana but that would not add any any more detail to this discussion. The test.osm file here is rural America but in Arizona by the border with Mexico. People who live in this area are either retires or work for the border patrol. <a href="https://drive.google.com/open?id=1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN" target="_blank">https://drive.google.com/open?id=1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-">
> Depending on the craft mapper, hand drawn buildings can have the same<br>
</span>> problems. [...]<br>
<br>
As i have been very clear about this is not the case:<br>
<span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-"><br>
> > Microsoft's process documentation contains a number of hints that<br>
> > indicate things can go wrong in the process in ways that are likely<br>
> > to produce significant errors of kinds that are very unlikely to<br>
> > happen in manual mapping.<br>
<br>
</span>The only thing that could convince me to change this assessment would <br>
be - as already mentioned - a thorough analysis of the quality that <br>
holds up to scientific scrutiny. And it is frankly much more likely <br>
that such analysis would confirm my impression. If it does not that <br>
would mean Microsoft has made progress in the field that absolutely <br>
dwarfs everyone else working in the area and if that was the case we <br>
would see it on the stock market. ;-)<br>
<br>
Don't make the mistake of assuming this to be a building data set like <br>
various ones produced by local authorities or mapping institutions some <br>
of which have been considered for import or have been imported in the <br>
past. It is not. Therefore again my statement: IMO this means that a <br>
<span class="m_8147913065387054115m_-4891386143055581201m_-463345994464745014gmail-m_-863059944255234068gmail-">proper import review would only be possible based on a thorough <br>
analysis of the quality of Microsoft's product that holds up to <br>
scientific scrutiny.<br></span></blockquote><div><br></div><div>Continuing on with the sun burnt analogy, if I wear a high blocking sun screen I will not get burnt as much. I could careless about the mapper's assessment from Alaska. His imagery is leaf on compared to my imagery which is leaf off. Because I live in a desert, I will have fewer issues than the Alaskan mapper's data set. There are no trees hanging over the buildings in question. Here's what I have done so far to protect myself from claims on both sides i.e. the data is good and the data is bad.</div><div><br></div><div>* So I see that there will need to be some checking done as part of the import process. Here are some early observations of the CNTK process that MS used with 32 GPUs.</div><div><br></div><div>* The we have many solar panels in Arizona because of a state mandate. Many of these are used as covered parking. The tag of yes would have to change to roof. That can happen during the import or as a second QA pass. </div><div><br></div><div>* The Q in JOSM will be required for some of the black topped roofs or solar panels.</div><div><br></div><div>* It is curios that some of the black roof or darker colored roofs are missed. When I craft map, sometimes I get interrupted, sometimes I get bored and I never get back to the missing buildings. Oh well! Either another mapper comes along and picks up the missing work or sits for awhile. That is what I mean by the data is no better nor no worse than a normal volunteer's work flow.</div><div><br></div><div>*
<span style="font-family:arial,helvetica,sans-serif;font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">All the round buildings are square. That may be the result of CNTK making sure that buildings are square. The work around is to add a few more nodes and hit the O key in Josm</span></div><div><br></div><div><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">* I noticed one or two buildings where they included a concrete slab as part of the building. The X tool in JOSM will be used to scale back that part of the building. Again, I've had to clean up these kinds of issues with other craft mappers including myself. Buildings that I mapped from the prior version of Bing or Yahoo, are clearer with the last Bing imagery release in my area.</span></font></div><div><br></div><div>* The imagery in this area of the test.osm file is satellite based. It is not of the same high quality .5 meter and below I get to use in the metro Phoenix area. Moreover, the metro Phoenix are is flown imagery so most of it is very high nadir. MS states that they have a number of sources of imagery providers. The buildings still look respectable.</div><div><br></div><div>* There was one school that I was puzzled why it came out the way it did. This is a non issue because there is an existing building. The Bing building will be deleted.</div><div><br></div><div>I have to dash. Perhaps I can post some screen shots of the test.osm file. What I have done so far is to have two layers in Josm to compare the data with the existing OSM data. The test file is here <a href="https://drive.google.com/file/d/1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN/view" target="_blank">https://drive.google.com/file/d/1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN/view</a> . The whole Google drive folder is here <a href="https://drive.google.com/open?id=1FhQd8fSIbx9OyG6vFAaKkBfYn10Rw0Da" target="_blank">https://drive.google.com/open?id=1FhQd8fSIbx9OyG6vFAaKkBfYn10Rw0Da</a> . The information may be useful to other mappers considering the Bing footprints. Arizona is one of the larger data files. I can parse other states if that will be helpful to other US Mappers. And yes I was going to looke at both Wyoming and Montana.</div><div><br></div><div>Regards,</div><div>Greg</div><div><br></div><div>
<br></div><div><br></div><div><br></div><div><br></div></div></div></div>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div></div>