Hi all- Have there been any ideas about how we want to handle the import process?
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: 1. Write a project-level wiki page with standard instructions and tips with community feedback 2. 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. 3. Get a few volunteers from the community who can serve as "project managers" to offer guidance and validation 4. 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 5. We all use a special #bingbuildings changeset hashtag so that we can monitor and track progress 6. Optionally, set up a project in the OSM-US tasking manager when the import is complete for validation purposes by the community at-large. 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. Thanks, Andrew On Wed, Jul 4, 2018 at 12:32 PM Greg Morgan <dr.kludge...@gmail.com> wrote: > > > On Wed, Jul 4, 2018 at 1:34 AM, Christoph Hormann <o...@imagico.de> wrote: > >> >> Greg, >> >> I will comment on a few of the new things you have written but like to >> emphasize this is still not an import review because a lot of >> information required for that is missing. You could however read up >> old discussions on previous building imports here to get an idea on the > > requirements and suggestions made for those. >> > > Got it. It is not a review but a helpful number of ideas. Thank you for > your time. > > >> > [...] In my early opinion, the foot prints are no >> > better nor no worse than a craft mapper,s drawing >> > > > >> This is always a pretty meaningless comparison because it is apples and >> peaches. When i talk about "quality aspects" i mean quantifiable >> measures of quality. >> >> > [...] As your >> > other post provided an idea of starting with Montana, that will not >> > be useful in my case. >> >> I suggested rural Montana might be a good place to start if you >> intend "to poke the data for quality issues". Since that is not what >> you want to do my suggestion is pretty useless for you obviously. >> >> > > Microsoft's process documentation contains a number of hints that >> > > indicate things can go wrong in the process in ways that are likely >> > > to produce significant errors of kinds that are very unlikely to >> > > happen in manual mapping. Without having reliable data on how >> > > often these things do happen (and how this varies between different >> > > geographic settings) you would essentially be doing a blind import. >> > >> > > 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. > https://drive.google.com/open?id=1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN > > > >> > Depending on the craft mapper, hand drawn buildings can have the same >> > problems. [...] >> >> As i have been very clear about this is not the case: >> >> > > Microsoft's process documentation contains a number of hints that >> > > indicate things can go wrong in the process in ways that are likely >> > > to produce significant errors of kinds that are very unlikely to >> > > happen in manual mapping. >> >> The only thing that could convince me to change this assessment would >> be - as already mentioned - a thorough analysis of the quality that >> holds up to scientific scrutiny. And it is frankly much more likely >> that such analysis would confirm my impression. If it does not that >> would mean Microsoft has made progress in the field that absolutely >> dwarfs everyone else working in the area and if that was the case we >> would see it on the stock market. ;-) >> >> Don't make the mistake of assuming this to be a building data set like >> various ones produced by local authorities or mapping institutions some >> of which have been considered for import or have been imported in the >> past. It is not. Therefore again my statement: IMO this means that a >> proper import review would only be possible based on a thorough >> analysis of the quality of Microsoft's product that holds up to >> scientific scrutiny. >> > > 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. > > * 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. > > * 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. > > * The Q in JOSM will be required for some of the black topped roofs or > solar panels. > > * 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. > > * 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 > > * 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. > > * 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. > > * 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. > > 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 > https://drive.google.com/file/d/1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN/view . > The whole Google drive folder is here > https://drive.google.com/open?id=1FhQd8fSIbx9OyG6vFAaKkBfYn10Rw0Da . 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. > > Regards, > Greg > > > > > > _______________________________________________ > Imports mailing list > impo...@openstreetmap.org > https://lists.openstreetmap.org/listinfo/imports >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us