John, Exprime tu simplement une opinion, ou as-tu vérifié les procédures d'import incluant correction des données et validé la qualité des données importées aux États-Unis ? Considères-tu la qualité des données dans la base OSM aux États-Unis comparable à ce qui s'est fait au Canada l'an dernier ?
La qualité des données Microsoft peut sans doute varier selon divers facteurs dont la qualité et précision des données aériennes utilisées. De mon côté, j'ai regardé du côté de Dallas, Texas. En consultant le gestionnaire de tâches US, il est possible d'y repérer les tâches créées pour cartographier des bâtiments. https://tasks.openstreetmap.us/contribute?difficulty=ALL&statuses=ARCHIVED&types=BUILDINGS Dans ces zones, j'ai constaté en général une bonne qualité des données. Je ne connais pas les procédures utilisées, ni regardé le connu des fichiers de données Microsoft pour ces zones, mais la tâche ci-dessous montre un processus de validation où il était demandé d'orthogonaliser les bâtiments.https://tasks.openstreetmap.us/project/164#bottom Pierre Le vendredi 17 janvier 2020 13 h 02 min 20 s UTC−5, john whelan <jwhelan0...@gmail.com> a écrit : > As stated before, I don't consider the Microsoft dataset being close tothe >minimum quality requirements I would expect from any automated building entry into OSM. Well yes that is one opinion but we do have a range of opinions in OpenStreetMap and from the number of buildings that have already been imported into OpenStreetMap from Microsoft, there seems to be a large number in the US for example, it would appear there are those who disagree with you which is not surprising given the number of mappers. To me the buildings are of more interest once they get enriched with more tags and the place that happens is in OpenStreetMap. Streetcomplete I think is either the most popular editor these days or very close to it. You can't add tags if the buildings are not in OpenStreetMap. Yes you can display the outlines by using the Microsoft data but that does not show tags such as building type, building levels, etc etc. and streetcomplete is a tool that can be used to introduce OpenStreetMap to many people. I think perhaps we should concentrate our efforts on the current import for the moment but I suspect that some Microsoft buildings will start to be imported in Canada even if they don't have an official import plan. Cheerio John On Fri, 17 Jan 2020 at 12:12, Tim Elrick <o...@elrick.de> wrote: Hi John, As stated before, I don't consider the Microsoft dataset being close to the minimum quality requirements I would expect from any automated building entry into OSM. If you just want to display buildings, you can download the MS dataset and use it right away - no need to import into OSM. I think, the MS dataset has value as proof of concept and to count the number of buildings in a given area (e.g. to estimate market size for roofers, estimate number of persons living there for desaster relief, etc.). I also think, when Microsoft feeds its algorithm with higher resolution data than they did (I don't recall, but I think they only used the regular Bing data) they will probably end up with building footprints that will meet our/my quality requirements for import into OSM one day. For me, the value of OSM is having accurate information in terms of tags and geometry. Otherwise, we could join Wikimapia; they don't care too much about geometry accuracy but emphasize on content/tags of objects. Pretty interesting project, but different from OSM. Cheers, Tim On 2020-01-17 10:40, john whelan wrote: >first, to add missing buildings (if it were just for this purpose we could also use the much bigger Microsoft dataset) I can't resist. Does this infer that for parts of the country without Stat Can data we are happy to import Microsoft dataset buildings as is? Or would we wish to wait until we have some more imports done before looking at preprocessing them in some way first. Thanks John On Thu, Jan 16, 2020, 10:11 PM Tim Elrick, <o...@elrick.de <mailto:o...@elrick.de>> wrote: I would assume in most cases the imported building footprint will be more precise than existing data. For me, this would be a reason to replace already existing objects. However, I think this is a case by case decision. However, I think it is important to keep tags and history of buildings already existent in OSM. This is how I would read/interpret the import guideline stated by Nate: "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." (emphasis added by me) However, that just means, the import, hence, is nothing easy and could not be achieve quickly, I would assume. One way of making sure that this is dealt with diligently, would be setting the tasking manager to 'experienced mappers only'. We would have to ask James, who is in charge of the Canada Tasking Manager, how to edit/set up the 'experienced mapper role' in the TM. It might be possible to feed in a list of mappers manually or to set a threshold of objects/changesets that they must have entered in OSM. However, maybe only mappers who feel experienced enough to handle the import would contribute to the TM project anyway and we let everyone judge on their own and don't restrict access. If we were to separate the new and overlapping buildings, I am also leaning towards Daniel's assessment. I would be afraid to cause more issues than by doing it all at once (with a reasonable tile size, of course). In the end, the main point of importing this specific dataset fulfils two purposes, in my opinion: first, to add missing buildings (if it were just for this purpose we could also use the much bigger Microsoft dataset), second, to get the best geospatial representation possible in our OSM database. That means, we defer from using the Microsoft dataset and use the much higher quality data from the ODB. This also means that we should replace already existing buildings (yet keeping tags and history) wherever the ODB footprint is more precise than the existing one. Just my two cents here, Tim _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-ca _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca